We generally leave deployment out of scope of the individual modules.

Our intention is to have a consistent deployment process throughout all the courses (e.g. same tools). That question is currently bundled into the "final projects" conversation, since we were going to start there and work backwards to the other exercises/projects.

If there is a specific React reason/topics regarding deployment, we could still cover something here, but i think the tools, process, and the general introduction might be covered elsewhere.

Are you sure a week is enough?

To properly teach them how to use Next.js? Definitely not.
My suggestion would be to treat it as an introductory session or workshop — a starting point for those who might want to dive deeper into this more powerful tool. The Next.js team actually offers a fantastic several-hour course that explains the framework’s key concepts and usage in a very accessible way.

If trainees could take that course as homework, the session itself could focus more on exploring why we need a framework like Next.js, what problems it solves, and how to approach it effectively. Then yes, 1 week should be enough

+1 to this

Are you sure a week (1 class) is enough for all this?

I think we need to consider what the learning goals of this module are, to know.

Our course mission here is to get people into a junior frontend position, so what about next.js and how much of next.js do they need to understand/have experience with to have the biggest impact on their success rate of getting a job? Can we teach them enough about nextjs to make it worthwhile?

On the two extremes, for example, we could simply introduce why they might use next.js, basic concepts, and some exercises to show what next.js is and some jumping off points for trainees to go deeper themselves post graduation. That could fit in one week.

If instead we decide understanding next.js can have a really big impact in the employment rate, then we could help people learn how to use next.js themselves, more advanced concepts, and practice a lot more with bigger exercises/projects. Then we might decide more than one week is necessary.

I know I just added more questions than answers 😇

More questions more fun! 🤩

I'm not arguing for or against it here, although you kind of have to use a framework with React and Next is an obvious choice given it is the most popular and the "official" React framework 😄. This proposal seems to want to run it on Vite as well which is the most similar framework to the older version of React.

I would just like to point out that everything that is mentioned under Weeks 3 and 4 respectively might be difficult to cover in one class without expecting students to prepare a lot for it.

Okay, answering your questions one by one 😄
Warning: long read 🫠 But I find important in this discussion to share my whole thought process around this point.

Are you sure a week (1 class) is enough for all this?

I’m not entirely sure — but let’s see.
If we skip Reducers, then Context isn’t that heavy of a topic — it’s essentially just an advanced way of handling state. Routing (the classic approach, not file-based) is mostly about using if conditions with Components and a params hook, so it shouldn’t be too challenging either.

As for libraries — when I last taught this, I simply introduced the idea that they exist, showed how to install them, and gave one example (e.g. how to add a Button). Most of the time we spent the first hour of each session on Q&A, and the only question I got on this topic was about restyling MUI (which even trips up professionals 😆). I didn’t notice a lot of struggle there. Actually, I think it’s great that trainees are learning to explore libraries on their own — it’s a crucial skill to be able to read documentation effectively.

All of these topics aim to help trainees take their apps from being super-primitive to something more polished. Technically, you don’t need Context or libraries to build an app — they’re more of a “making your life easier bonus” than must-know fundamentals.

I know I just added more questions than answers 😇

Those are great questions, @adamblanchard. Do we have any stats on that? 😅
Until we do, I lean more toward the first option you mentioned. I’ve shared more about my vision for the Next.js part (at this time) in this comment: #65 (comment)

although you kind of have to use a framework with React

That’s not exactly true. Vite isn’t a framework—it’s build tooling, similar to Webpack. A framework typically dictates how you write your code and introduces high-level concepts for solving common problems. In contrast, build tools allow you to write “pure” React and freely choose your own libraries.

Frameworks only became popular relatively recently — and for good reasons. React covers only the “view” layer of an application and doesn’t offer out-of-the-box solutions for routing, data fetching, or state management. Over time, the community converged on mainstream libraries like react-router to fill those gaps. Frameworks emerged later to solve more advanced problems that React itself wasn’t designed to handle: performance, server rendering, and SEO. These are real challenges, but they’re also quite advanced — and many frontend developers rarely deal with them directly. For example, if you’re building an internal tool, Lighthouse scores are far less important than speed of delivery and low bug count.

it is the most popular and the "official" React framework

That’s also not entirely accurate — especially if we consider Vite a framework (though technically it’s not). Frameworks absolutely shine in scenarios where performance, SEO, or fullstack capabilities are important, and in those cases, Next.js is definitely the go-to choice. But it’s not necessarily the default tool for all frontend development — at least not from what I see in practice. When those advanced needs aren’t present, simpler tools like Vite or Webpack are often preferred because they let you focus on the core of your app without added complexity.

Stack Overflow Survey 2024 confirms that Next.js is a very popular framework, but it’s still used by less than half of React developers. Meanwhile, Vite and Webpack are listed in a separate section (since they’re not frameworks), so the comparison isn’t apples to apples — but it does suggest that many developers still opt for build tools over frameworks when appropriate.

Personally, I use all of them 😄
At my last job, we chose Next.js for the wrong reasons — mainly because it was new, trendy, and widely recommended. Unfortunately, we ended up with poor performance and random errors, simply because we didn’t have the right use case for it (and continued to do normal React way there).

At my current job, we’re using pure React with Vite as the bundler, and honestly, there’s no way we could justify switching to Next.js. From a business perspective, there just aren’t any compelling arguments — it would add complexity without solving any real problems for our use case.

older version of React

React hasn’t changed drastically since hooks were introduced. Most of the newer features — like server-side components — are geared toward framework developers, not everyday React developers. And yes, those framework developers are very happy not having to use workarounds anymore. 😄

But when we use a build tool instead of a full framework, we can really focus on learning React itself — without having to wrestle with framework-specific constraints from the very first day.

I would just like to point out that everything that is mentioned under Weeks 3 and 4 respectively might be difficult to cover in one class without expecting students to prepare a lot for it.

Week 3 is actually the same size as before — the only change is replacing "rendering multiple components" with "refs", which aligns very natural with Events there.
As for Week 4, I’ve already elaborated on it earlier.

Good points @chezzoba. I like your proposal @markitosha. It might be hard to fit all of it in but too be fair, it already was. I think it is a good idea that we take a critical look at it and shave away anything not strictly needed.

Overall very nice proposal. You present the idea very clearly and I think it all looks good. ⭐ Also great overview with the diagrams.

What kind of material are you referring to here? videos, blogs etc. any specific links you have in mind?

This one is "to be researched", to be honest.
I don't know much resources besides official documentation (I rarely use something besides official documentation in general), but I know that people learn different ways, and maybe have video/blog/etc explaining React basics could benefit for a lot for trainees

From my experience, this amount of matherial might become 4-hours-lecture instead of 4-hours-practice

I agree! Hence, the "main" topic for each week (see my comment further down 👇) — but yes, finding preparation material is a challenge.

Improve beyond React documentation

I do find https://react.dev very good, though. I have used exercises from the site in Sunday sessions, as they can be solved inline and come with a "reveal solution" button. However, for more visual learners a video or two for each week would be great. Maybe it could be a compilation of YouTube tutorials that reach the bar of being up-to-date, easy to understand and therefore good for preparation?

I very much like us to use Vite

Yes, that's a good take. Even in the very last session of React 2 we always had to write "use client" in page files, as SSR in Next.js is challenging at best, and does not use the concepts we teach (e.g. hooks).

I don't like to rely on client-side only, but I find that the ecosystem is still stuck there. SSR is still not a first-class citizen and therefore teaching React client-side seems like a good place to start and absolutely in-line with teaching job-landing skills.

I agree that it makes sense to integrate the meal sharing app with this module. Maybe the homework could be related to the meal sharing.
I had the initial idea with React that:

• Week 1 - make a very simple static page from a few components. Could be an "about" page.
• Week 2 - make a more complex static page where some components are reusable. I.e. a landing page with a more advanced layout of content etc.
  • For the sake of making the exercises more engaging maybe we should introduce just a button onclick so the trainees can see things happen and see React "Reacting".
• Week 3 - Add more complex interactivety to the page, form inputs, loading wheel and api integration. i.e. the main feature page
• Week 4 - Tie it all together, add routing and make it "shine" (or put out burning fires from previous weeks).

This is similar to the way it works today. Some of the assignments are related to Meal Sharing. One issue I found as the mentor, is the disconnect between lesson plan / exercises and Meal Sharing. I have no overview of when trainees are working on what and am entirely unprepared when they ask some Meal Sharing related question in or after the sessions. I don't have a good solution to fixing this (as I could probably invest the time to follow the Meal Sharing project, which would improve the situation), but it comes up every time I teach React. 😭

I am leaning towards not teaching Reducers. I don't think a new joiner would be expected to know that and it is hard to really teach them why using such a pattern is good if they haven't worked with a large app.

How much effort is required to deploy to the cloud somewhere? If possible, I would love to move this to week 1 to really hammer it in early.

It takes a couple of clicks in Vercel + can be integrated with PRs without additional settings (so we have "free" deployment for every homework for both modules, yay)

And Vercel is developing Next.js, so it is definitely go-to instrument for easily deploying it

I believe that for free deploys repositories need to be public, but otherwise, yes, we should demo this. It's like magic and a moment of success for everyone, to have a "hello world" up and running.

Very nice proposal. I agree with the topics.

Can we design a mini project for this module which highlights the benefits of Server side rendering or static site generation?

Yes! I like this section a lot. Next.js should be the cherry on top 🍒, not a thick and chewy bottom layer 🍰

Some thoughts:

• SSR & SSG — It was very hard for me to explain these concepts as they require some knowledge on the part of the trainees about how a browser works, how servers work, the history of the internet, SPAs, SEO, 100 more abbreviations and such. It's a bit of a mouthful to explain this all in one go.
• That being said, I think they got the gist of "you can pre-render your website and get HTML" and "you can have a server render your website on every request". But that is the (surface) level at which we stopped, basically.
• Now, using these techniques in Next.js is a whole other beast. Since they don't use the same mechanisms (especially hooks), it's like a whole new world to start in.
• Additionally, things like getServerSideProps are just no fun when using plain JavaScript, so that's very hard to visualize how the data flows when Next.js renders the page on the server
• Making an app with SSR require quite some planning, e.g.
  • Which data do I want to be there on first load?
  • Do I want interactivity on the client-side? How do I combine this with SSR?
  • Is my data accessible on the server?
  • What features of Next.js in the realm of SSR and SSG do I want to use? How do I opt-in to those? How do I configure them properly?
• This is basically a master class, in my opinion 🤷

Just look at this bullet from the app router -> pages router migration guide 🤯

Only saying getServerSideProps, getStaticProps, getStaticPaths and generateStaticParams without mixing them up takes me five minutes, and I haven't yet explained what they do, or what the new APIs do they have been replaced with and, how these APIs work and what fantastic names they have...

• Next.js App Router — we need to make sure to communicate what approach we're using and what the difference between the app router / pages router models is (what is the difference?!). The Next.js docs can still switch between the two approaches they have, and you can land on a page through a search engine that is for the wrong mode. I haven't been using Next.js at work since this was introduced, so I was completely lost the first time and am almost completely lost still 😬 (might be a me problem, though)
• API Routes can be nice to show, because this is quite transferable to how Lambdas etc. at many Cloud Providers work as well
• I love Server Actions, because they tie back neatly to how <form> from HTML + CSS works, but they seem more like master class material to me too … 🥮

how a browser works, how servers work, the history of the internet, SPAs, SEO, 100 more abbreviations and such

I've tried to explain all of that last time I taught React 2, I lost trainees in about 15 minutes 😆

app router / pages router models is (what is the difference?!)

I don't need we need to tech pages router, it is kind of deprecated at this point.

I love Server Actions, because they tie back neatly to how <form> from HTML + CSS works, but they seem more like master class material to me too …

It is nearly impossible to create a real application without using Server Actions, I'm afraid. As soon as you have to update any data -- you either have to use hooks and do the old client way, or you use Server Actions. I use them all the time when I'm too lazy to have a proper API endpoint, tbh 😅

Week 4 diagram has reducers twice

I think state management libraries falls in the same category as Reducers. I don't think it is required to land your first job and it is quite hard to teach why all the added overhead of the library is good to the trainees who has never seen a large project before. I would rather focus on:

• Context
• Routing
• Icon libraries
• (optionally, component libraries if time allows)

Yes, I agree. Under "state management libraries" I meant only mentioning that Context is not the only way to solve the problem and maybe drop a couple of names they might hear here and there. They'll research if they are interested. The same approach I suggest to "component libraries"

I previously mentioned SWR for data fetching and state management, but trainees mostly didn't get why I would introduce it and got confused.

They see useEffect + useState online and it mostly works, so that's what I show now. (Even though, following the React team, we're supposed to move away from using useEffect for anything other than syncing with external systems ... 😬)

I'm still waiting for useFetch natively in React 🙏

(And really, this is the only "state management" most applications really need – fetching and caching data from the source of truth, which most often is a JSON API. All other state can be managed within useState of pages, components, and context, if needed)

I would consider if refs are required. I am not experienced in it but it seems more of an advanced feature only needed in edge cases.

I think it is so React-specific thing, that it worths at least mentioning.
Also it kind of builds the bridge between what they know about browser and what React does. Last time I explained it like "constant that saved between renderings without causing updates" :D Didn't have much questions about it

I introduced refs in React 2 and it was not very successful. Trainees did not see the point of using Refs. In my opinion, Refs are something you learn when you have a need for them. It's a very specific feature of React and not standard knowledge. I'd vote to remove them from the curriculum.

I, actually, showed a couple of examples from my real repo at work, and it felt like it had more sence for them after that (there was work with timers, when you store result to be able to cancel them without component update)

I find the analysis of the issues of the Next.js version of the curriculum very concise. It is a mix of framework-specific and React-related topics. And the level of difficulty is very mixed as well, making it hard to follow and teach.

The only thing I will mention positively from using Next.js is the file-based router ✅ . It took 20 minutes to explain this to trainees (and they didn't notice how this works before explicit explanation), but once they understood that it's just like when they were writing html files and you could find them by their name when serving a directory, it clicked for them (path variables were another story, though).

The decoupling of routing and files can be very hard to understand for a beginner. And typos, routing priority, wildcards etc. do not make this any easier.

That being said, I'm not aware of any React Router-ish modules that could do something similar (translate a folder structure to a router setup), which would give us the benefit without needing to introduce Next.js and all of its intricacies?

A thing to keep in mind is that – at least in Aarhus – we've been using Next.js for the final project to simplify setup 🏁. I'm not sure if it actually accomplishes that goal. I do know that trainees were very frustrated when we didn't use Next.js, but express and React, and they didn't know why the backend was started on port x and frontend on port y etc. With Next.js we didn't have these problems, but other problems, like the two different file-based routing models Next.js has and how Lambda functions work for API calls etc. So, there's that...

Update: So, I read the whole proposal now, and Next.js is in the end. See my comment there 👇

There is actually some examples of file-based routers in https://github.com/vitejs/awesome-vite 🤔 We can think of using those, but this is up to a discussion, I think

To the drawing:

• What do you mean by "Use {} in JSX"?
• What do you have in mind for "Sharing state"?

In general, I feel like there is too much "main" content in every week. I'd take one or two main topics for the week and then do some asides to cover necessary tangents.

In my experience it's very overwhelming when we present a long list of topics for a day. When presented with "Today we're going to learn about "State"", trainees seem more engaged, as they don't have to keep a laundrylist of topics in mind, but instead we naturally land onto things like "fetching from an API into the state". Those would be "sub-topcis" in my opinion.

But branding the day with one or two overarching learning goal(s) seems like a good strategy in my experience. You've kinda done this in Week 2.

It is the same staff we have in the plan right now: "Use {} in JSX" is Embedding Expressions in JSX, "Sharing state" is about props drilling.

I agree that it is overwhelming, but I don't see how we can structure differently without drastically removing content 🤔 If you have something in mind, that would be amazing

confidently create applications using React

I'm not sure if this a bit too optimistic 😳 Certainly, that would be the goal. But even with years of experience, you may not "confidently" create React apps. Depending on the complexity and your (JavaScript) skills. What do you think about this?

After completion, trainees should be able to create simple applications and websites using React

From my experience, this amount of matherial might become 4-hours-lecture instead of 4-hours-practice

I agree! Hence, the "main" topic for each week (see my comment further down 👇) — but yes, finding preparation material is a challenge.

Improve beyond React documentation

I do find https://react.dev very good, though. I have used exercises from the site in Sunday sessions, as they can be solved inline and come with a "reveal solution" button. However, for more visual learners a video or two for each week would be great. Maybe it could be a compilation of YouTube tutorials that reach the bar of being up-to-date, easy to understand and therefore good for preparation?

Yes, that's a good take. Even in the very last session of React 2 we always had to write "use client" in page files, as SSR in Next.js is challenging at best, and does not use the concepts we teach (e.g. hooks).

I don't like to rely on client-side only, but I find that the ecosystem is still stuck there. SSR is still not a first-class citizen and therefore teaching React client-side seems like a good place to start and absolutely in-line with teaching job-landing skills.

Maybe we could add "render Props" and JSX props? I find they can make a beginner happy, when they first understand that they can pass JSX or a function returning JSX as a prop down the tree. It's just very powerful and you can do creative stuff with it, once you understand it. But maybe too advanced as well?

I introduced refs in React 2 and it was not very successful. Trainees did not see the point of using Refs. In my opinion, Refs are something you learn when you have a need for them. It's a very specific feature of React and not standard knowledge. I'd vote to remove them from the curriculum.

How would you approach Routing, now that we're not using Next.js? Plain React Router setup, following their "Getting Started"?

I believe that for free deploys repositories need to be public, but otherwise, yes, we should demo this. It's like magic and a moment of success for everyone, to have a "hello world" up and running.

Yes! I like this section a lot. Next.js should be the cherry on top 🍒, not a thick and chewy bottom layer 🍰

Some thoughts:

• SSR & SSG — It was very hard for me to explain these concepts as they require some knowledge on the part of the trainees about how a browser works, how servers work, the history of the internet, SPAs, SEO, 100 more abbreviations and such. It's a bit of a mouthful to explain this all in one go.
• That being said, I think they got the gist of "you can pre-render your website and get HTML" and "you can have a server render your website on every request". But that is the (surface) level at which we stopped, basically.
• Now, using these techniques in Next.js is a whole other beast. Since they don't use the same mechanisms (especially hooks), it's like a whole new world to start in.
• Additionally, things like getServerSideProps are just no fun when using plain JavaScript, so that's very hard to visualize how the data flows when Next.js renders the page on the server
• Making an app with SSR require quite some planning, e.g.
  • Which data do I want to be there on first load?
  • Do I want interactivity on the client-side? How do I combine this with SSR?
  • Is my data accessible on the server?
  • What features of Next.js in the realm of SSR and SSG do I want to use? How do I opt-in to those? How do I configure them properly?
• This is basically a master class, in my opinion 🤷

Just look at this bullet from the app router -> pages router migration guide 🤯

Only saying getServerSideProps, getStaticProps, getStaticPaths and generateStaticParams without mixing them up takes me five minutes, and I haven't yet explained what they do, or what the new APIs do they have been replaced with and, how these APIs work and what fantastic names they have...

• Next.js App Router — we need to make sure to communicate what approach we're using and what the difference between the app router / pages router models is (what is the difference?!). The Next.js docs can still switch between the two approaches they have, and you can land on a page through a search engine that is for the wrong mode. I haven't been using Next.js at work since this was introduced, so I was completely lost the first time and am almost completely lost still 😬 (might be a me problem, though)
• API Routes can be nice to show, because this is quite transferable to how Lambdas etc. at many Cloud Providers work as well
• I love Server Actions, because they tie back neatly to how <form> from HTML + CSS works, but they seem more like master class material to me too … 🥮